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STRUCTURED FINANCE TRANSACTION ANALYTIC SYSTEM 

AND METHOD 

FIELD OF THE INVENTION 

The present invention generally relates to a system and 
5 method for tracking and analyzing structured financial transactions and 
more specifically to a system and method for tracking and analyzing 
Collateralized Bond Obligations and Collateralized Loan Obligations. 

B ACKGROUND OF THE INVENTION 

Collateralized Bond Obligations (CBO) and Collateralized 
0 Loan Obligations (CLO) (collectively Collateralized Debt Obligations, 
CDO) are financial instruments in which bonds or conunercial loans are 
pooled and securitized and notes or participation certificates are sold to 
investors. A CBO/CLO is a structured securities transaction (or deal as is 
known in the art) in which the seller is typically denoted as the issuer (or 
5 originator) and the buyers are one or more investors. The notes or 

participation certificates are the liabilities of the CBO/CLO, while the 
assets of the deal are the securities that collateralize the CBO/CLO. 
Securities are the equity or debt (bond, loan, note) instruments that may be 
issued or owned by a deal. Debt securities consist primarily of bonds and 
0 loans that are purchased by a deal. 


01/25997 


PCT/USOO/26985 


-2- 

The issuer is the legal entity that has the authority to offer its 
own bond, note or stock certificate for sale to investors. For instance, an 
issuer can issue bonds, be the borrower on a loan, and can be the business 
entity that sets up the special purpose vehicle referred to as the deal. 
Issuers of structured financial securities are those entities who generate 
financial assets in the normal coxirse of their business. Such issuers 
include, but are not limited to, banks, thrifts, mortgage companies, 
manufacturers and distributors with a financing division, retailers with 
credit card or other finance operations, consumer finance companies, 
specialty finance companies, equipment lessors, asset aggregators, or any 
other business enterprise that generates substantial quantities of trade 
receivables. 

Investors include, but are not limited to, insurance 
companies, banks, thrifts, mutual funds, and private investors. Other 
interested parties with respect to a deal include rating agencies, insurers, 
research firms, investment banks, and accounting firms. 

The first structured transactions occurred in the late 1980s 
and provided an important means for troubled financial institutions to 
dispose of their high yield bond portfolios. Subsequent structured 
transactions have given investment managers another tool to increase their 
"assets under management" and banks a means of moving assets off of 
their balance sheets and/or provide less expensive and stable funding 
sources. Figure 1 illustrates a simplified diagram of the structure and 
typical entities involved in a deal 100. The deal IOC is structured in 
accordance with one or more documents, such as an Indenture. This is the 
primary dociraient that govems the deal, including the roles of a rating 
agency 105, a financial advisor 1 10, a sponsor or collateral manager 115, 
and a trustee or collateral administrator 120. The financial advisor 1 10 is 
typically an underwriter such as an investment bank (e.g., J.P. Morgan, 
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Goldman Sachs...). The sponsor/collateral manager 115 often holds equity 
in the CLO/CBO 100. 

The primary responsibility of the trustee/collateral 
administrator 120 is to represent the investors in the management of the 
5 CDO 100. This management responsibility includes cash management, 

making trades, making payments, processing assets, testing the deal 100 for 
compliance and administering tlie collateral, all in accordance with the 
Indenture agreement. In the context of a large structured finance, the 
trustee 120 is typically one out of fom: or five large financial institutions 

10 (e.g., Chase Manhattan Bank), Figure 1 also illustrates the portfolio assets 
125 and the securities 130 involved in the deal. 

One significant problem associated with the prior art is the 
difficulty experienced by trustees 120 and collateral manager 1 15 in 
assembling, tracking and managing a large number of complex deals . 

15 Historically, the management process has been very manually intensive, 

despite the use of computers and databases. In fact, the widespread use of 
computers has actually made the management of a CDO 100 more 
complex. Typically, the various information required for active CD^ 
management is found on a variety of different systems with a variety of 

2 0 different formats and access requirements. The lack of interoperability of 
these various systems has made the management process that much more 
dependent on manual oversight. The manual process is costly and can lead 
to errors if the proper checks and balances are not incorporated into the 
systems and processes of the trustee 120 and the collateral manager 115. 

25 Furthermore, the manual nature of prior art process leads to redundant 

efforts as many of the issuers, assets, information sources, etc. are common 
to several deals. 

Another significant drawback of the prior art is ability to 
generate reports reflecting the status of the CDO 100, including the 
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performance of the underlying assets. Regular reporting requirements are 
typically imposed upon the trustee/collateral administrator 120 by the 
Indenture agreement. Investors are often interested in the performance of 
the underlying assets securitizing the CDO 100 because it could affect the 
5 timing and amount of income received on the security or tlie ability to be 
repaid the principal of the security. The Indenture agreement will typically 
require that the issuer prepare periodic reports concerning the status of the 
underlying pools of assets 125. This task is typically assigned by the issuer 
to the trustee 120 , For example, wheiLa pogLgf^sets^lZS^cpm^ 
10 ^mnber ^^ issuer m ay^e boundlo_ ^ 

provide status to the investors on the underlying loans. The status may 
include, for example, principal collected, interest collected, fyf^c^osures. 
prepajTiients, losses, delinquencies, whether trigger thresholds have been 
reached, etc. 

15 Due to the manually intensive nature of the systems and 

methods of the prior art, the conventional reports prepared by the trustee 
120 are difficult to prepare and are often limited in the type and nature of 
the information contained in the report. Further, each report generated by 
the trustee 120 relates to only a single deal. It is not possible, therefore, for 

2 0 these reports to provide information as to the performance of a portfolio of 
underlying assets from more than one deal. For example, if an investor 
were interested in the asset performance of all assets originated by issuer X 
in the same year, then those assets would likely securitize obligations 
related to more than one deal. The conventional reports, therefore, would 

2 5 not provide the investor with the information desired. 

An additional problem with the prior art systems is their 
inability to adapt to increasing complexity of CDO 100 due to the evolving 
structures of new CDOs 100 and the inclusion of more varied types of 
assets used as collateral such as derivatives, Real Estate Investment Trusts 
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(REITs), commercial mortgages and amiuity payments or other payment 
streams (e.g., tobacco settlements). 

Accordingly, there is a need in the art for a new method and 
system for assembling, tracking, managing and reporting on a plurahty of 
CDOs that are collectively associated with a huge number of assets and 
securities. 

SUMMARY OF THE INVENTION 

The present invention provides an integrated system and 
method for assembling, tracking, managing and reporting on CDOs. The 
present invention allows for global asset administration, includes multiple 
asset categories (including loans), has cashflow capabilities, provides 
interfaces to various financial information services and includes tlie 
capability for clients to access the system for retrieving and reviewing 
various information with respect to deals, proposed deals, and hypothetical 
trades. 

The system includes databases for issuers, collateral, deals, 
countries, trust accounting, ratings, payments, receipts and all other data 
required to manage deals. Since all of the deals operate off of these 
common databases, as data changes, the change is instantaneously reflected 
in all the deals. 

Some of the significant components of the system of the 
present invention include client service functions, client management, deal 
management and ^ollateraLa dmi^gg|tion, calculating agent management, 
paying agent management, trust accounting, collateral asset processing, 
custody, note and note holder management and payment, cash flow 
management and conmion data services. Some of the interfaces to the 
outside world from the system of the present invention include a client 
interface, an interface to rating services, interfaces to various payment 
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facilities (e.g., SWIFT) and interfaces to various other banking institutions. 
A significant aspect of the present invention is the client interface. The 
system of the present invention allows clients (collateral managers, 
trustees, investors) to access the system either through the Internet or 
5 private value added networks or through direct dial lines. The system 
includes the appropriate security such that unauthorized access to the 
system is prevented. Furthermore, each user of the system is only able to 
view data which he/she had been authorized to view. The client interface 
further provides for export of reports such as hypothetical testing reports 

10 and compliance testing reports. 

Another significant capability of the present invention is the 
ability to formulate and execute hypothetical trades. Using this function, 
collateral managers are able to propose hypothetical trades, hypothetically 
execute these trades, and view the resulting effects on the deal. 

15 Compliance testing during the hypothetical execution informs the collateral 
manager as to whether or not such a hypothetical trade would be allowed 
under the Indenture. Once the hypothetical trade data has been input and 
tested, the user is able to actualize (execute) the trade. 

Using the cash flow management portion of the present 

2 0 invention, the user is able to quickly view the projected cash flow 

transaction, actualize cash flows, and compare the projected to actual cash 
flows. Actual payments and receipts are fed firom other systems in order to 
update the databases of the system of the present invention. 

Other objects, features, and advantages of the present 

2 5 invention will be apparent to one skilled in the art from the following 

description of the invention with reference to the accompanying drawing. 


BRIEF DESCRIPTION OF THE DRAWING 
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For the purposes of illustrating the present invention, there is 
shown in the drawings a form which is presently preferred, it being 
understood however, that the invention is not limited to the precise form 
shown by the drawing in which: 
5 Figure 1 is an illustration of the structure and various parties 

to a structured finance transaction; 

Figure 2 illustrates the system of the present invention for 
assembling, tracking, managing and reporting on CDOs; 

Figure 3 A-3D illustrates the main user interface with respect 
10 to input, update and maintenance of issuer data; 

Figure 4A-4H depicts the user interface with respect to 

securities; 

Figure 5A depicts the main deal inteifiice; 

Figure 5B illustrates the deal detail user interface; 
15 Figure 5C shows the user interface with respect to collateral; 

Figure 5D depicts the note interface; 

Figure 5E shows the interface associated with roles; 

Figure 6 depicts the user interface for scenarios; 

Figure 7 illustrates the cash flow transaction interface; 
2 0 Figures 8 illustrates the report interface; 

Figures 9-12 illustrate sample pages from a typical report 
generated by the present invention; 


DESCRIPTION OF THE PREFERRED EMBODIMENT ... 

Figure 2 illustrates the system 1 50 of the present invention 
2 5 for assembhng, tracking, managing and reporting on structured finance 
transactions. As seen in this Figure, the system 150 integrates several 
functions and databases into a single seamless system 150. The core 
functional components of the system 150 include: Client Management 160; 
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Client Services 170; Deal Management and Collateral Administration 180; 
Calculating Agent Management 190; Paying Agent Management 200; and 
Trust A ccounti ng 210. Support components of the system 1 50 include: 
^C^lat^][A s^r^cessing^^ 230;^^r^dNote-Holder^ 


Data Services 260; Messaging 270; and a Payment System 280. Further 
illustrated in Figure 2 are the interfaces to the external world including 
clients 295, other banks 272-278, payment transfer systems 282, and rating 
services 290. 


functions of Account Management 162, Query Resolution Tracking 164, 
Product Marketing 166, and Account Performance Tracking 168. These 
tools 162-168 are used by the Relationship Manager (RM) to manage the 
relationship with the clients. The Account Management Function 162 
allows the RM to view the status of all of the deals in which a particular 
client is currently participating or has participated. To accompHsh this 
function, Account Management 162 uses the data contained in the various 
databases of the system such as the Deal Data 184 and the consolidated 
Collateral Asset Data 1 86. Similarly, the Account Performance Tracking 
module 168 allows the RM to track the performance of the deal for any 
particular client. Client Management 160 further provides a function for 
Query Resolution Tracking 164 when cUents have questions conceming 
their accounts. The Product Marketing component 166 allows the RM to 
generate marketing materials for presentation to existing or potential clients 
(e.g., performance data related to past deals, or the historical performance 
of a particular issuer). 


Input 172; Data/Report Export Facility 174; Hypothetical Testing and 
Reporting 176; and Compliance Testing and Reporting 178. The Client 




;ement and Paym^^40; Cashflow Management 250; Common 


The Client Management component 160 performs the 


Client Service Functions 170 include: Hypothetical Trade 
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Service Functions 170 provide the main interface to system 150 for 
Client's 295. In a preferred embodiment of the present invention, clients 
access system 150 through the Internet using the appropriate security 
mechanisms such as encryption, password protection, firewalls, etc. (not 
shown). Alternatively, clients 295 can access system 150 through a direct 
dial line or other private network connection. 

The ability of clients 295 to access the system of the present 
invention and view data in real time is a significant advantage of the 
system 1 50 over the prior art. In the prior art, the primary method by 
which clients (e.g., investors) received any information regarding deals was 
either through paper or electronic reports (e.g., Excel™ spreadsheets). 
Using the present invention, clients 295 are able to sign onto the system 
and generate and view reports themselves. Although not illustrated in 
Figure 2, in addition to normal security procedures (firewalls, 
passwords...), the data of the present invention is protected by autliorization 
methods. Data can only be accessed by a user, if the user has been granted 
access (authorization) to view the data. Similar protections exist for 
functional components of system 150. For example, a client 295 would not 
be able to access the payment system 280 for the transfer of fimds. 

As will be further described below, the hypothetical trade 
input component 172 allows a client 295 to propose hypothetical trades 
with respect to a deal. This component 172 accepts the input data fi-om the 
client 295 for the proposed hypothetical trade. The interface module 172 
provides this hypothetical trade data firom the client 295 to the hypothetical 
trade module 188 for the calculation of the results of the hypothetical trade. 
The Data/Report Export facility 174 is responsible for generating and 
exporting various reports for clients 295. Reports can be run for a variety 
of reasons such as supplying information with respect to a client's trade 
portfolio. Reports are typically required by the Indenture agreement to 
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provide investors with the status of deals. Reports in accordance with the 
present invention can provide historical data on trades in cash flow 
transactions as well as reports regarding hypothetical trades run with 
respect to a particular deal. 
5 The hypothetical testing and reporting module 176 operates 

on the data input via interface module 172. As fiirther described below 
with respect to the Compliance Testing and Report Module 178, the 
hypothetical testing module 176 allows clients 295 and Portfolios 
Managers to test proposed trades to sec how they affect the overall 

1 0 structure and performance of a deal with respect to the compliance rules 
required in the Indenture. The results of the hypothetical testing can be 
reported in the same manner as described below with respect to the actual 
compliance testing. 

The Compliance Testing and Report Module 178 is used to 

15 ensure that a current deal is in compliance with the Indenture governing the 
deal. Compliance testing and the reports generated are discussed below in 
connection with Figures 8 and 9-12. 

Deal Management and Collateral Administration 1 80 is the 
core component for the Deal Management aspect of the present invention. 

2 0 Module 1 82 is the module by which deals are initially established and 

subsequently maintained. The Deal Data database 184 contains all of the 
data specific to particular deals such as contact points, investors, assets 
contained in the deal and accounts associated with the deal. The 
Consolidated Collateral Assets Data Database 186 contains all of the data 

25 related to all of the assets contained in all of the deals maintained in the 

system. Element 188 is a database which contains temporary data which is 
used by hypothetical testing reporting module 176 to run hypothetical trade 
scenarios as more fully described below. Module 187, Actualize 
Hypothetical Trades, is used to execute the trades contained in a 
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hypothetical scenario previously run by the Hypothetical Testing and 
Reporting module 176. 

Element 190 is the Calculating Agent Management 
component. Module 192 provides for review and approval by the 
5 Relationship Manager of the results of any hypothetical testing and 
reporting 194 and compliance testing and reporting 196. Module 198 
calculates the deal specific principal and interest with respect to the notes 
and securities contained in, and associated with a deal. 

Paying Agent Management 200 is responsible for monitoring, 

10 payment and reception of payments associated with deals. Element 202, 
Note and Note Holder Details Advising and Monitoring, determines when 
payments are required to be made with respect to the notes associated with 
the deals. Element 204, Payments and Receipts Processing, performs the 
actual payment and receipt management in conjunction with the cash flow 

15 management module 250 described below. Waterfall Calculation section 

206 performs the traditional waterfall calculations known to those skilled in 
the art. The indenture sets forth the rules (priorities) as to how funds are to 
allocated (e.g., principal and interest payments). The waterfall calculation 
section 206 carries out, implements, these rules fi"om the indenture. 

2 0 Element 210 performs all of the traditional trust accovmting 

functions required of a trustee such as Financial Reporting 211, Tax 
Reporting 212, Trust Reporting 213, Account Reconcilement 214, 
Accounting 215, Account Setup and Maintenance 216, and Special Purpose 
Vehicle (SPV) accoxmting 217. The trust accounting functions are the 

2 5 traditional functions performed by a trustee but have been greatly 

facilitated by the integrated nature of the present system 150. For example, 
all of the data required for these function is now available in a single 
system 1 50. 
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CoUateral asset processing 220 provides a support function of 
gathering data with respect to the assets contained in the deals. This data is 
then fed to Consolidated Collateral Asset Data database 186. The raw data 
with respect to the collateral originates from agent or custody banks 272- 
5 278 and is preferably transmitted to the system of the present invention 
using secure XML Messaging 270. The raw data from the agent banks 
272-278 is then converted and loaded into the processing section dealing 
with the type of asset (see element 208, data converters/loader). There is a 
different processing section for each type of collateral, loans 202, bonds 

1 0 204 and other types of assets 206. 

Element 230 contains a custody module 232. Custody is a 
traditional trustee function in which the trustee holds the actual asset in 
trust. The custody module 232 tracks the custody of the collateral assets 
maintained in the system. Element 240 manages and processes payments 

15 on notes to note holders. Module 242 contains the details with respect to 
each note associated with the deals as well as details with respect to the 
note holders. Component 244 contains the specific payment instructions 
with respect to each note holder (e.g., payments in U.S. dollars to bank 
account XYZ). 

20 Cash Flow Management Section 250 manages the cash flows 

from the accounts associated with each of the deals. Module 252 projects 
cash flows that are to be realized by each of the deals. Component 254 
compares the projected cash flows from a deal to the cash flows actually 
experienced by the deals. Component 256 executes the actual payments 

25 and receives the receipts with respect to the deals. These payments and 

receipts are typically processed through payment system 280 which has an 
interface with industry standard electronic funds transfer systems such as 
SWIFT orFedwire282. 
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Element 260 provides common database services. Two of 
the databases contained in this component are Common Data (e.g., LIBOR, 
Country Holidays...) 262 and characteristics of the assets used as collateral 
264. The characteristic data is retrieved from various rating services 290 
such as Moody's™ or Bloomberg™. 

In initially establishing the system of the present invention, 
several of the databases of the system must be initially populated. One of 
the core databases includes all of the information related to issuers. As 
previously described, the term issuer refers to a legal entity that has the 
authority offer its own bond, note, or stock certificate for sale to investors. 
For instance, an issuer can issue bonds, be the borrower of a loan, and can 
be the business entitj' that sets up the special purpose vehicle referred to as 
the deal. Figure 3 A illustrates a screen shot of the user interface to the 
system of the present invention with respect to issuers. The issuer window 
300 is separated into four separate tabs: Search 302; Issuer Detail 304; 
Aifihate 306; and Credit Rating 308. 

When the issuer window 300 is initially brought up, it 
displays an alphabetical listing of all of the issuers including bonds, loans 
and notes existing in the database in area 322 of window 300. In the 
example depicted in Figure 3 A, the database has already been populated 
with a plurality of issuers. During the initial set up of the system of the 
present invention, area 322 is blank since there are no issuers to display. In 
order to add an issuer, the user uses his or her input device (e.g., a mouse) 
to activate a pop-up menu 310. Pop-up menu 310 provides the user with 
the ability to add, delete, find issuers, to scroll the list of issuers or to 
retrieve or sort the issuer list. Following conventional windows standards, 
there are multiple ways to navigate and perform activities within the 
system of the present invention. Activities can be performed using mouse 
actions or keyboard actions, or a combination of both. Although only 
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described in detail with respect to this interface 300, other interfaces of the 
system of the present invention provide the same or a similar pop-up 
window 310 to provide additional functionality. 

When the user selects the add function from pop-up menu 
5 3 10, the window 330 associated with the issuer details tab 304 is presented 
to the user as depicted in Figure 3B. In the issuer details window 330, the 
system prompts the user for the issuer name 3 12, the coimtry of the issuer 
314 and whether or not the issuer is a sovereignty 33 1 . A sovereign issuer 
represents a government as opposed to a corporate issuer who represents a 

10 corporation. This distinction becomes important when running collateral 
quality tests. The percentage of sovereign issuers and non-sovereign 
issuers are typically part of the collateral debt service requirements. The 
user is further requested to provide the tax ID 332 of the issuer, the 
company name 316 and the first 318 and last name 320 of the contact at the 

15 issuer. As illustrated in Figure 3a, the directory listing of issuers includes 
the issuer name 312, the country of the issuer 3 14 the company name 316, 
and the first 318 and last name 320 of the issuer contact. 

The affiliates tab 306 opens up a window 340 for entry of 
information related to affiliates of the issuer as depicted in Figure 3C. 

20 Affiliates are groups of companies, such as holding companies in which a 
corporate parent/subsidiary relationship exists, and in which the affiliates 
are financially related to each other. The issuer is the parent company 
while the affiliates are typically the subsidiaries. The affiliates window 
340 displays a list of candidate afiBliates 341 which can be established as 

2 5 affiliates of the issuer using conventional drag and drop methods on the 
afiBliates window 340. The affiliate relationship is established when the 
issuer name 342, the effective date 343 and the discontinued data 344 are 
completed in window 340. 
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The credit rating tab 308 opens up a user interface 345, as 
illustrated in Fig. 3D, that displays the selected issuer's credit rating. Prior 
to clicking on credit rating tab 308, the user must select one of the issuers 
displayed in area 322 (in window 300, Figure 3A). Using the input device 
5 (e.g., mouse), the credit rating for an issuer is obtained from one of several 
rating service sources (see 290 in Figure 2), such as Bloomberg™, 
Standard and Poors™ or Moody's™. For a new issuer, the credit rating is 
added by selecting the information source 346, selecting a rating 347, and 
entering the effective date 348 when the rating is in effect and a 
10 discontinued date 349 (if applicable) which is the date the rating expires. 
Credit ratings are used by many type of issuers such as bond issuers, 
borrowers of loans, and business entities that set up special purpose 
vehicles. 

One of the elemental types of data contained in the system of 
15 the present invention is the security. Figure 4A illustrates the main 

window 350 with respect to secinities. The information contained in the 
system regarding securities is separated into eight separate tabs in window 
350: Search 352; Detail 354; Price 356; Interest Schedule 358; Credit 
Rating 360; Contacts 362; Default History 364; and CUSIP History 366, 
20 As vidth the issuer window 300 illustrated in Figure 3A, activation of the 
search tab 352 on the security window 350 brings up a list of all of the 
secxnities contained in the databases of the system. As seen in Figure 4A, 
the securities are listed in alphabetical order. The securities are listed by 
the issuer name 370, the security name 371, the Committee on Uniform 
2 5 Securities Identification Procedures (CUSIP) 372, the International 

Standard Identification Number (ISIN) 375 the Bloomberg™ number 375 
and the security type 374. 

In order to add a new security to the database, the user brings 
up a pop-up menu associated with the window and selects the Add 
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function. The Add function activates the window 380 associated with the 

Detail tab 354 as illustrated in Figure 4B. The security detail window 380 

allows the user to input the issuer name 370(a borrower in the case of a 

loan), the type of security 374 (e.g.., bond, loan, note, etc.), the security 
5 name 371, the CUSIP 372, the ISIN 373, the Bloomberg™ identifier (if 

any) 375, the amount of the original principal 383, the settlement location 

384, and the registration type 385 (or loan type, e.g., term, revolving). If 

the type of security selected is a loan, the user is prompted to enter 

Reference ID 381 and Facility ID 382. The security detail window for 
10 notes and contracts types of security are essentially the same as the window 

for loans, less the loan type and loan sub-type fields. 

If the type of security selected is a bond, the user is prompted , _^ , 

to check the Bloomberg report to see if the bond is prefunded, if the bond J-,. 

has warrants attached, if it is convertible and if it is callable 386. If the w 
1 5 bond is callable, the user additionally needs to set up a call schedule in the i 

database for the bond. The call schedule requires a beginning and ending 

date and the call price as shown in Figure 4C. 

The price tab 356 Figure 4C opens a user interface 400 in 

which the user is able to indicate a market information source 401 and the 
2 0 price 402 of the security as well as an effective date 403 and a discontinue 

date 404 for the price. An example of a market information source is 

Bloomberg™. 

The interest schedule tab 358 opens up a user interface 

window 410 as illustrated in Figure 4D that enables the user to input. the 
2 5 interest schedule associated with the particular security being added or 

modified. The user is prompted to select either a floating interest rate or a 

fixed interest rate 411. If the fixed interest rate is selected, the user is 

prompted to enter the interest accrual date 412 (the first date the interest 

begins to accrue on the security) the 1^ coupon date 413, the maturity date 
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414, the payment frequency 415 and the convention used for day counting 
416. If the rate type is floating, the user enters the index upon which the 
rate is calculated 417, the spread 41 8, the cap rate (the highest rate the 
security will adopt) 419, the floor rate (the lowest rate that the security will 
5 adopt) 420 and an override rate (if applicable) which is a rate that will be 
effective for a certain period of time and will override a previously entered 
rate for a specific security and calculate daily checkbox, 421 . For both 
fixed and floating rates, the user enters a country name 422 which v^U 
determine the holidays observed with respect to the payments regarding the 
1 0 security. The country holidays are contained in the common data database 
262 (see Figure 2). 

Since all of the deals maintained in the system use a common , . 

database, any change made to the security interest schedule for a specific .^^ 

security will have a cascading effect on all deals that have an open position ^ 
15 in that security. Any change affects projected transactions after the date of 

the latest actualized transaction with respect to that security. 

The credit rating tab 360 opens a window 430 as illustrated in ; 

Figure 4E that allows the user to input a market information source 43 1 , a 

credit rating from the market information source 432 and an effective date 
2 0 433 and a discontinue date 434 for the credit rating. Again, since the deals 

use a common database, any changes to the security credit ratings will have 

a global effect on all of the deals having an open position in that security. 

The credit rating interface 430 fixrther allows the user to use an implied 

credit rating 435. In inputting an implied credit rating, the user identifies 
2 5 the security from which the current securities credit rating is implied, as 

well as a spread from the credit rating of the underlying security 436. In a 

preferred embodiment, an implied credit rating is used for informational 

purposes only. If a security has an implied credit rating, it is not 
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necessarily automatically adjusted as the underlying securities credit rating 
changes. 

The contacts tab 362 opens a window 440 as illustrated in 
Figure 4F in which the user can input the contacts for the security including 
5 the company name 441, the first and last name 443, 442 of the contact, the 
tax ID of the company 444 and Role type 445. The window 450 associated 
with the Default History tab 364 as shown in Figure 4G enables the user to 
input any history of default with respect to the selected security. The 
window prompts the user to enter the defaulted reason 45 1 and the 

1 0 effective 452 and discontinued dates 453 of the default. 

The CUSIP history tab 366 opens a window 460 as shown in 
Figure 4H that allows a user to modify the CUSIP of a security. The user 
is prompted to enter the old CUSIP 465, the new CUSIP 461, user created 
462 and the effective and discontinue dates 463, 464, 

15 As previously described, the main purpose of the system and 

methods of the present invention is the management of deals. Figure 5A 
illustrates the main user interface 500 (the search window) with respect to 
deals. The search tab 502 is used to view this main window 500. As 
illustrated in Figure 5 A, the directory of deals includes the issuer name 

2 0 520, the deal code 522, the deal name 524, the AMTrust account number 
526, the closing date 528 and the sequence number 530. As described with 
respect to the previous windows, the user employs an input device in order 
to activate the pop-up menu 532. The user then selects the add function in 
order to add a new deal. 

25 As illustrated in Figure 5B, activating the add button brings 

up the user interface 550 associated with the deal detail button 504. The 
first piece of information required in adding a new deal is the issuer name. 
By selecting the issuer name button 520 on window 550, the directory of 
issuers previously described with respect to illustrated Figure 3 A is brought 
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up for review by the xxser. The user can select one of the issuers from this 
directory for inclusion in the deal. It should be noted that an issuer can be 
the issuer of a deal as well as the issuer of a security contained in a deal. 

In area 524, the user provides a name for the deal and in area 
5 552 inputs the type of deal (e.g., CBO, CLO). The deal type refers to the 
majority of assets held by the deal. For instance, a collateralized bond 
obligation (CBO) would hold mostly bonds as its assets while a 
collateralized loan obligation (CLO) would hold mostly loans as its assets . 
Collateralized debt obligations (CDO) deals can be made up of mosdy 

1 0 bonds or loans. The user inputs the AMTrust account 526 established for 
the deal. The user further inputs the earliest mature date 554, the latest 
mature date 556, the effective date 558 and the closing date 528. 

As further illxxstrated in Figure 5B, the deal has a single 
AMTrust account 526 but is able to have many sub accounts (560). Sub 

15 accounts are used to track cash transactions posted to or transferred from 
one account to another. Sub accounts are also used to record cash flow 
items such as purchases, sales and principal and interest payments. Sub 
accounts must be linked to transactions in order to default to the correct sub 
account when a cash transaction is created. The accounts/transaction 

2 0 relationship must be set up before any transactions are created for the deal. 
Typically, the required sub accounts are provided in the Indenture 
governing the deal. 

Such accounts typically include a custodial account, a 
collection account, a pajment account, and an unused proceeds account. 

2 5 For each accoimt associated with the deal, window 550 depicts the sub 

account type 562, the sub account AMTrust number 564 and the balances 
566 contained in each account. Using a separate window (not illustrated) 
the user is able to transfer money between accounts. 
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The user is able to add in additional deal information to the 
records associated with the deal. This information includes: an abstract 
that summarizes the deal points (monthly report date, due period and 
payment date); the account transactions rules that maps allowable 
5 transactions to specific accounts and designates cash in/cash out and 

principle/interest; the asset categories which are set up as identified in the 
Indenture (additional asset categories can be added as necessary). The 
Indenture outlines the number of categories that are included in the deal 
defines the types of collateral to be assigned to each category, and defines 

10 the classification in which the n Qtes^(obligations ) for the deal are assigned 
to an advanced rate matrix. The obligations are entered according to the 
temis of the Indenture for the pxupose of building the advance rates table 
and determining the advance amount. The advance amount is calculated by 
multiplying tlie calculated amoimts by the advance rates and totaling each 

15 column. This function is performed in a report section described below. 
The advanced rates are entered into the matrix as identified in the 
Indenture. The purposed of the matrix is to: calculate the advance amounts 
and determine the discounted collateral value; identify the information 
sources such as a Bloomberg™ feed of Moody's™ and S & P™ ratings; 

2 0 identify the permitted classifications which defines the industries and 
regions as used in the diversity test (described below); identify the 
permitted values that are used for identification of other characteristics of 
each security; identify the security type; and identif>' the trade groups 
associated with the deal. 

2 5 Transactions are events that occur against a deal such as the 

purchase or sale of a security or an interest projection. In setting up a deal, 
the user is prompted to enter accoxmt transaction rules that are used to set 
up which accoimt 560 (e.g., collection account, payment accoxmt) against 
which the transaction will be credited (cash-in) or debited (cash-out). The 
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system includes a list of default transactions which can be selected to be 
applied to a deal. Each transaction has a name, a type, a cash type, a cash 
flow and the account associated with the transaction. An example of a 
transaction is a collateral principle payment. This transaction would have 
the type collateral, the cash type principle, a cash flow of cash-in and a 
default account of the collection account. As transactions occur with 
respect to the deal, the user is able to select from the transactions allowed 
for the deal to define the transaction, and more importantly the account 
which the transaction will impact. 

Figure 5C illustrates the window 600 associated with the 
collateral tab 506. This window 600 depicts all of the securities 602 
currently maintained in the deal as well as all of the actual and projected 
transactions 616 related to the deal. With respect to collateral 602, for each 
security, window 600 lists the settlement location 604, the security type 
606 (e.g., bonds, loans, etc.); the security name 608; the CUSIP 610; the 
Aggregate Original PAR 612 owned by the deal; and the Aggregate 
Current PAR 614 owned by the deal. 

For each actual or proposed transaction 616 associated with 
the deal, window 600 depicts the transaction name 618, the cash flow 620 
(e.g. cash in or cash out) the transaction date 622, the amoimt of the 
transaction 624, the type of transaction 626 (projected or actual), the 
principle 628, the interest rate 630, and the number of days in the accrual 
period 632 as well as the accrual begin and end dates 634, 636. 

Figure 5D illustrates the window 650 associated with the note 
(obUgations) tab 510. Displayed in this window 650 are all of the notes 
652 associated with the deal. For each note, the following is described: the 
pay down priority 654; the CUSIP 656; the security name 658; the investor 
type 660; and the original principal amount 662. As with the collateral 
screen 600 depicted in Figure 5C, the note window 650 displays all of the 
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transactions 664 of the deal with respect to the outstanding notes. The 
information for each transaction is the sanie as has been described above 
with respect to the transactions 616 in the collateral window 600 (see 
Figure 5C). 

5 Figure 5E depicts the user interface 670 associated with the 

role assignment tab 612. Each of the roles in the deal 672 are listed in this 
window. For each role, the following information is provided: the role type 
674 (each of the role types for the deal is listed in the Indenture); the 
company name 676; the first and last names of the person fulfilling the role 
10 678, 680; the effective date of responsibilit>^ 682; and the discontinue date 
684, Area 686 on window 670 contains potential candidates for each of the 
roles. These potential candidates are maintained in the database of the 
system. 

Once the database of the system of the present invention has 
1 5 been populated (issuers, securities, deals) one of the significant features 
and advantages of the present invention is thus enabled. Namely, 
executing real and hypothetical trades. In order to execute real or 
hypothetical trades, the user generates a scenario for the trade which 
contains the details of the trade. The main screen for scenarios 700 is 
2 0 illustrated in Figure 6. Before entering this scenario screen 700, the user 
was presented with a list of securities to buy or sell. In the particular 
example illustrated in Figure 6, the right hand portion of the window 700, 
known as a trade ticket, has already been populated with the name of the 
security 702 selected for the transaction by the user, the CUSIP 704 for the 
2 5 security and the ISIN number 706 for the security (in this particular 
example, the security did not have an ISIN number). The user is then 
prompted to fill in the trade date 708 and the date of settlement for the 
trade 710. The user further selects whether the trade is a hypothetical trade 
712 or a real trade 714. The user then indicates in area 716 whether or not 
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the trade is a buy or a sell of the security. In area 7 1 8, the user is able to 
indicate whether or not this trade is grouped together with other similar 
trades in a trade group if making a purchase. For example, an initial 
purchase of a security maybe grouped with initial purchases of other 
securities into one trade group. When selling, the system prompts the user 
for a reason for the sale in order to verify that the sale is one permitted by 
the rules of the indenture. 

If the trade relates to the purchase of a bond security, the user 
enters the value to be purchased in the original PAR value field 720. For 
such a purchase, the current PAR value field 722 will default to the original 
PAR value. The user can override this default. The user then enters the 
price in field 724, The principal cost 726 and the premiimi/discount fields 
728 are automatically calculated and filled in by the system of the present 
invention. The user then fills in the aceoimt 730, 732 to be debited for a 
premium or credited for a discount. 

Real trades affect the balances of the accounts associated 
with the deal (see 560 in Figure 5B), Hypothetical trades are used for 
"what if testing. The results of the hypothetical trade can be viewed using 
the reporting feature of the present invention as further described below. 
Once all of the data related to the trade has been entered, the user can save 
the data in the database. As previously described, if the trade is a real 
trade, the appropriate databases and balances in the system are updated 
while if the trade is a hypothetical trade, the data will be stored in a 
separate database (see 1 88 in Figure 2). As seen on the left hand portion of 
window 700, each of the scenarios 734 for the chosen deal are displayed. 

Another significant advantage of the present invention is the 
ability to perform cash flow transactions. The main screen 750 for cash 
flow transactions is illustrated in Figure 7. Cash flow transactions include 
the purchase or sale of securities, receipt of interest and principal, receipt of 
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reinvestment income, payment of notes and payment of fees and 
borrowings on loans. The present invention allows the user to more readily 
discover input errors because it eliminates the use of multiple reconciliation 
points. 

The cash flow management window 750 illustrated in Figure 
7 can be accessed from many different areas. The user can be directed to 
this window 750 from a selected deal, sub account, note or role assignment 
(see Figures 5A-5E). Each of the projected and actualized transactions 752 
are displayed in the cash flow management window 750. For each 
transaction, the following information is displayed: the bock date 752 (the 
date of the posting of the transaction); the account 754 from which the 
transaction flows (cash out) or into which the transaction flows (cash in); 
the transaction type 756 (e.g., collateral interest) the type of cash flow 758 
(cash in oi' cash out); the type of transaction 760 (projected or actual) the 
projected amount 762 of the transaction scheduled to be received or paid; 
the actual amount 764 of a transaction which has been actualized (received 
or paid); the actual total 766 (the sum of the transactions that have been 
actualized against a projected transaction); the actual date 768 (defaults to 
the present date) and the actual amoimt 770 (the amoimt of the nansaction 
that is being actualized.) 

Area 772 illustrates the account balances as of the book date 
for a selected transaction. These amounts include the balance of the 
principal that has already been actualized 774, the amount of interest 776 
that has been actualized, the cash due in from principal 778 according to 
the projections, the cash due in from interest from projections 780, the cash 
due out of principal 782 (including the total projected and actualized 
principle amounts due out by the last book date) and the same for interest 
amounts 784, the due balance of principal 786 (the amount of the 
unreceived principal) and the amount of the unreceived interest 788. 
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In area 790, the user is able to select different variables which 
can be used to tailor the search criteria for performing cash flow 
transactions, e.g., filtering. The filtering functions allows the user to select 
all sources of data for the cash transaction screen 750 (notes, collateral, and 
5 role types for the deal) or filter only one of collateral, note or role. The 

user can further define a beginning date and an end date for transactions to 
be displayed in window 750. The user can further filter using a transaction 
name, the account name or the transaction type. The selected filter criteria 
will determine which transactions are displayed in area 752 on window 
10 750. 

The user is able to actualize a projected transaction using the 
cash flow management window 750. To actualize a projected transaction, 
the user selects the transaction in area 752. The actual date 768 must 
match the book date 752. If the actual date does not match the book date, 

15 the user can alter the actual date. Once the dates match and the projected 
amount 762 is equal to the amount the user wishes to actualize, the user 
clicks on the actualize button 792 and clicks on the Save button 794 to 
complete the actualization of the transaction. If the user wishes to actualize 
a different amount firom the projected transaction amount 762, the user 

2 0 types in the actual amount desired to be actualized in field 764 and clicks 
on save. 

The user is also able to add unscheduled cash flows to the list 
of transactions 752. In order to add such an unscheduled cash flow, the 
user brings up the previously described pop-up window and selects add. 
25 The user is then able to fill in the book date 752, select an account 754, 

select a transaction 756, and the cash flow 758, select "actual" and the type 
760. The user then enters the amount in the actual field 764 and clicks the 
Save button 794 to add the unscheduled cash flow. 
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A further significant feature of the present invention is its 
ability to generate and export reports regarding deals, securities, 
transactions, hypothetical trades, projected and actual cash flows and a 
variety of other information. The deal descriptor tab 508 on window 500 
(see Figure 5 A) enables the user to input further descriptive information 
with respect to each piece of co Uatera^ ontained in the deal. One of the 
descriptions which the user can input is reporting requirements including 
the report beginning and ending dates and the report due period beginning 
and ending dates. Typically, the Indenture requires at least monthly 
reports. The user can additionally define interim reports that can be run at 
any time to include a reporting period of a specific length greater or less 
than an month in duration. 

On the menu bar on the user interface (not shown) the user 
clicks a report button in order to bring up the initial report interface 800 
illustrated in Figure 8. On window 800, the user either types in the desired 
deal name in area 808 or selects a deal fi-om a drop down menu (not 
shown). Each of the scenarios for the deal are listed in area 810 of window 
800. The scenarios were previously defined by the user for performing 
trades (see Figure 6 and its associated discussion). The scenarios also 
include a monthly report 812 and an interim report 814 as previously 
described with respect to the deal descriptors added by the user. As 
previously described with respect to Figure 5E, each scenario for a user's 
hypothetical trade is listed in area 810. Hypothetical reports can be run 
against the hypothetical scenarios in order to test the viability of the 
proposed trade. The reports include all real trades currently in the system 
and additionally include all hypothetical trades included in the selected 
scenario. 

In order to run and view a report, the user selects run and 
view button 816 to begin a report of the most current data contained in the 
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database, based on the scenario selected. The report, once completed, is 
presented for viewing by the user. Alternatively, clicking on the run button 
8 1 8 alone begins a report of the most current data in the database. Clicking 
on the view button 820 will view the last report that was created. The 
present invention runs an exception report before any report. An exception 
report provides the user with a list of missing fields and if there is any 
missing data, an error message displays in the title of the report. If the user 
wishes to only run an exception report, checkbox 826 is activated. If the 
user wishes to suppress the running of the exception report, checkbox 828 
is checked. Once a report has been generated, it can be included an email 
to send to interested parties (e.g., investors)by using checkbox 830. In an 
alternative embodiment, the report can be posted on a secure website for 
access, viewing and/or downloading by the interested party. The report 
can also be exported to a disk file suing button 824 and the options in box 
832. 

Figures 9-12 illustrates sample pages firom a typical report. 
Page 950 in Figure 9 illustrates a summary page. Typically, the summary 
page 950 is the first of all reports and contains a summary of all the tests 
952 required by the Indenture. The siunmary page 950 also contains asset 
information, cash balances, information on liabilities, and portfolio 
information 954. The notes statistics section 956 of the summary page 950 
includes note name, outstanding balance and interest rate with respect to 
the selected deal. 

Figure 10 illustrates an index page 960 of the report. As can 
be seen in this Figure, the report run in this example contains 113 separate 
pages. In a preferred embodiment of the present invention, each of the 
entries on the index page is a hyperlink to the detailed page that supports 
the particular entry. In this manner, the user is able to drill down to the 
detailed information contained on any particular page of the report. In the 
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example report illustrated in this Figure 10, eleven different tests were run 
as part of this scenario including overcoUateralization tests, interest 
coverage tests, a diversity test, a maximum rating distribution test, a 
security sold test, a cumulative maturity profile test, an issuer rating 
5 distribution test, and a minimum average recovery rate test. The remainder 
of the report pages provide various information with respect to the scenario 
selected. 

Figures 11 and 12 illustrate pages associated with an interest 
coverage test. Window 970 in Figure 1 1 is an interest test page. This 

10 interest test page 970 contains the summary of the test that was performed 
against the scenario. The detailed results of the test are contained in a 
detailed schedule 980 as illustrated in Figure 12. In a preferred 
embodiment of the present invention, each of the tests will include the test 
page 970 and the detailed pages 980. 

1 5 Any report that is generated by the system of the present 

invention can be printed and additionally exported as an electronic file. 
This exporting feature is particularly advantageous as a relationship 
manager is able to electronically generate these reports and export them to 
all required and interested parties. Standard security techniques such as 

2 0 encryption are used to protect the confidentiality of any exported financial 
information. 

Although the present invention has been described in relation 
to particular embodiments thereof, many other variations and other uses 
will be apparent to those skilled in the art. It is preferred, therefore, that the 
2 5 present invention be limited not by the specific disclosure herein, but only 
by the appended claims. 
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We claim: 

1 LA system for managing Collateral Debt Obligations 

2 comprising: 

3 a user interface; 

4 a deal database, the deal database storing at least first deal 

5 data describing a first de al: 

6 a collateral asset database, the collateral asset database 

7 storing at least first collateral asset data describing a first collateral asset, 

8 wherein the first deal data is logically related to the first collateral asset 

9 data; and 

0 at least one processor coupled to the user interface, the deal 

1 database and the collateral asset database. 

1 2. The system bs recited in claim 1 , ftirther comprising: 

2 , secQnd-d eiaI data describing a second deaLan d stored in the 

3 deal database, wherein the second deal data is logically related to the first 

4 collateral asset data. 

1 3. The system as recited in claim 2, wherein changes in the 

2 first collateral asset data is automatically reflected in any processing by the 

3 processor of the first deal data and the second deal data. 

1 4. The system as recited in claim 1, further comprising: 

2 a trade module, wherein a user is able to input, through the 

3 user interface, a trade with respect the first deal. 

1 5. The system as recited in claim 4, wherein the trade 

2 involves the purchase or sale of a target collateral asset, the target collateral 
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3 asset being described by target collateral asset data stored in the collateral 

4 asset database. 

1 6. The system as recited in claim 5, wherein if the target 

2 collateral asset is being purchased, the first deal data is updated to be 

3 logically related to the target collateral asset data. 

1 7. The system as recited in claim 5, wherein if the target 

2 collateral asset is being sold, the first deal data is updated to indicate the 

3 sale of the target collateral asset. 

1 8. The system as recited in claim 4, wherein the trade is a 

2 hypothetical trade described by hypothetical trade data, the system further 

3 comprising: 

4 a hypothetical trade database, the hypothetical trade database 

5 storing the hypothetical trade data. 

1 9. The system as recited in claim 8, further comprising: 

2 a hypothetical trade testing module, wherein the hypothetical 

3 trade testing module determines flie effect of the hypothetical trade on the 

4 first deal. 

1 10. The system as recited in claim 9, wherein the 

2 hypothetical trade testing module further generates a report describing the 

3 determined effect of the hypothetical trade on the first deal. 

1 11. The system as recited in claim 8, wherein the 

2 hypothetical trade data describes a purchase or sale of a proposed collateral 

3 asset, the system further comprising: 
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4 an actualization module, the actualization module actualizing 

5 the hypothetical trade by executing the purchase or sale of the proposed 

6 collateral asset. 

1 12. The system as recited in claim 1, further comprising: 

2 a collateral asset data source interface, the collateral asset 

3 data source interface providing access to external sources of information 

4 related to collateral assets; and 

5 a collateral asset manager coupled to the a collateral asset 

6 data source interface and coupled to the collateral asset database, the 

7 collateral asset manager retrieving updated collateral asset data from the 

8 collateral asset data source interface and updating Hie collateral asset 

9 database using the updated collateral asset data. 

1 13. The system as recited in claim 12, wherein the updated 

2 collateral asset data is related to the firstiGollateraLasset^ and wherein the 

3 collateral asset manager updates the^rst-eoHateral-asset data using the 

4 updated collateral asset data. 

1 14, The system as recited in claim 12, wherein the updated 

2 collateral asset data is related to a*seeond'C©llateral-asset, and wherein the 

3 collateral asset manager adds the second-collatCTal-asset data to the 

4 collateral asset database using the updated collateral asset data. 

1 15. The system as recited in claim 1 , wherein the first deal 

2 data includes compliance rules governing the first deal, the system fiirther 

3 comprising: 

4 a compliance testing module coupled to the deal database and 

5 the collateral asset database, wherein the compliance testing module 
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6 performs a compliance test using the compliance rules and the collateral 

7 asset data contained in the collateral asset database. 

1 16. The system as recited in claim 1 5, wherein compliance 

2 testing module further generates a compliance test report describing results 

3 of the compliance test. 

1 17. The system as recited in claim 16, wherein compliance 

2 test report includes a sunmiary section and a detail section. 

1 18. The system as recited in claim 1 , further comprising: 

2 a calculating module coupled to the deal database and the 

3 collateral asset database, wherein the calculating module calculates 

4 principal and interest payments with respect to deals contained in the deal 

5 database using the collateral asset data contained in the collateral asset 

6 database. 

1 19. The system as recited in claim 1, further comprising: 

2 a payment module coupled to the deal database and the 

3 collateral asset database, wherein the payment module receive and makes 

4 payments with respect to collateral assets related to deals contained in the 

5 deal database using the collateral asset data contained in the collateral asset 

6 database. 

1 20. The system as recited in claim 1, further comprising: 

2 a cashflow management module coupled to the deal database 

3 and the collateral asset database, wherein the cashflow management 

4 module processes cashflows related to deals contained in the deal database 

5 using the collateral asset data contained in the collateral asset database. 
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1 21. The system as recited in claim 20, wherein the cashflow 

2 management module generates projected cashflows related to deals 

3 contained in the deal database using the collateral asset data contained in 

4 the collateral asset database. 

1 22. The system as recited in claim 20, wherein the cashflow 

2 management module processes actual cashflows related to deals contained 

3 in the deal database using the collateral asset data contained in the 

4 collateral asset database. 

1 23. The system as recited in claim 20, wherein the cashflow 

2 management module generates projected cashflows and processes actual 

3 cashflows related to deals contained in the deal database using the 

4 collateral asset data contained in the collateral asset database and wherein 

5 the cashflow management module further compares the projected 

6 cashflows to the actual cashflows. 

1 24. The system as recited in claim 1, further comprising: 

2 a rating service interface, the rating service interface 

3 providing an interface to rating services that provide collateral asset 

4 ratings, wherein collateral asset ratings retrieved through the rating service 

5 interface are used to update the collateral asset data stored in the collateral 

6 asset database. 

1 25, The system as recited in claim 1, further comprising: 

2 a country database, the country database storing country data 

3 including at least country holiday data describing holidays observed by a 

4 plurality of countries, wherein the country holiday data is used by the 
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5 processor when executing financial processing related to deals contained in 

6 the deal database. 

1 26. The system as recited in claim 1, wherein the first 

2 collateral asset is a note. 

1 27. The system as recited in claim 1, wherein the first 

2 collateral asset is a bond. 

1 28. The system as recited in claim 1 , wherein the first 

2 collateral asset is a loan. 

1 29. The system as recited in claim 1, wherein the first 

2 collateral asset is an equity. 

1 30. A method for managing Collateral Debt Obligations 

2 comprising: 

3 storing, in a deal database, at least first deal data describing a 

4 first deal; 

5 storing, in a collateral asset database, at least first collateral 

6 asset data describing a first collateral asset; and 

7 logically relating the first collateral asset data to the 

8 first deal data. 

1 31. The method as recited m claim 30, fiarther comprising; 

2 storing, in the deal database, second deal data describing a 

3 second deal; and 

4 logically relating the first collateral asset data to the second 

5 deal data . 
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1 32. The method as recited in claim 3 1 , further comprising: 

2 reflecting changes in the first collateral asset data in any 

3 processing of the first deal data and the second deal data. 

1 33. The method as recited in claim 30, fiirther comprising 

2 inputting a trade with respect the first deal. 

1 34. The method as recited in claim 33, wherein the trade 

2 involves the purchase or sale of a target collateral asset, the target collateral 

3 asset being described by target collateral asset data stored in the collateral 

4 asset database. 

1 35. The mediod as recited in claim 34, wherein if the target 

2 collateral asset is being purchased: 

3 updating the first deal data to be logically related to the target 

4 collateral asset data. 

1 36. The method as recited in claim 34, wherein if the target 

2 collateral asset is being sold: 

3 updating the first deal data to indicate the sale of the target 

4 collateral asset. 

1 37. The method as recited in claim 33, wherein the trade is a 

2 hypothetical trade described by hypothetical trade data, the method further 

3 comprising: 

4 storing the hypothetical trade data in a hypothetical trade 

5 database. 
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1 38. The method as recited in claim 37, further comprising 

2 determining the effect of the hypothetical trade on the first deal. 

1 39. The method as recited in claim 38, further comprising 

2 generating a report describing the determined effect of the hypothetical 

3 trade on the first deal. 

1 40. The method as recited in claim 37, wherein the 

2 hypothetical trade data describes a purchase or sale of a proposed collateral 

3 asset, the method fiirther comprising actualizing the hypothetical trade by 

4 executing the purchase or sale of the proposed collateral asset. 

1 41. The method as recited in claim 30, further comprising; 

2 providing access to external sources of information related to 

3 collateral assets; and 

4 retrieving updated collateral asset data from the external 

5 sources of information; and 

6 updating the collateral asset database using the updated 

7 collateral asset data. 

1 42. The method as recited in claim 41, wherein the updated 

2 collateral asset data is related to the first collateral asset, the method further 

3 comprising updating the first collateral asset data using the updated 

4 collateral asset data. 

1 43. The method as recited in claim 41, wherein the updated 

2 collateral asset data is related to a second collateral asset, the method 

3 further comprising adding the second collateral asset data to the collateral 

4 asset database using the updated collateral asset data. 
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1 44. The method as recited in claim 30, wherein the first deal 

2 data includes compliance rules governing the first deal, the method further 

3 comprising: 

4 performing a compliance test using the compliance rales and 

5 the collateral asset data contained in the collateral asset database. 

1 45. The method as recited in claim 44, further comprising 

2 generating a compliance test report describing results of the compliance 

3 test. 

1 46. The method as recited in claim 45, wherein compliance 

2 test report includes a summary section and a detail section. 

1 47. The method as recited in claim 30, further comprising: 

2 calculating principal and interest payments with respect to 

3 deals contained in the deal database using the collateral asset data 

4 contained in the collateral asset database. 

1 48. The method as recited in claim 30, further comprising: 

2 receiving and making payments with respect to collateral 

3 assets related to deals contained in the deal database using the collateral 

4 asset data contained in the collateral asset database. 

1 49. The method as recited in claim 30, further comprising: 

2 processing cashflows related to deals contained in the deal 

3 database using the collateral asset data contained in the collateral asset 

4 database. 
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1 50. The method as recited in claim 49, further comprising 

2 generating projected cashflows related to deals contained in the deal 

3 database using the collateral asset data contained in the collateral asset 

4 database. 

1 51. The method as recited in claim 49, further comprising 

2 processing actual cashflows related to deals contained in the deal database 

3 using the collateral asset data contained in the collateral asset database. 

1 52. The method as recited in claim 49, further comprising: 

2 generating projected cashflows related to deals contained in 

3 the deal database using the collateral asset data contained in the collateral 

4 asset database; 

5 processing actual cashflows related to deals contained in the / ' 

6 deal database using the collateral asset data contained in the collateral asset 

7 database; and 

8 comparing the projected cashflows to the actual cashflows. 

1 53. The method as recited in claim 30, further comprising: 

2 providing access to rating services that supply collateral asset 

3 ratings; 

4 retrieving collateral asset ratings from the rating services; and 

5 updating the collateral asset data stored in the collateral asset 

6 database with the retrieved collateral asset ratings. 

1 54. The method as recited in claim 30, further comprising: 

2 storing, in a country database, coxmtry data including at least 

3 country holiday data describing holidays observed by a pluraUty of 

4 countries; and 
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5 employing the country holiday data when executing financial 

6 processing related to deals contained in the deal database. 
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